Software systems, such as Enterprise Resource Planning (ERP) systems, are often used by organizations to perform the numerous and diverse computational tasks involved in conducting business. The software systems may involve many different software modules, which may also be customized to meet a specific organization's needs. Each time a module is installed, updated, and/or customized, it typically needs to be tested in order to verify that it operates as expected. Organizations often devote many resources for the purpose of testing and validating the performance of their software systems.
However, creating tests is not a trivial task. It is not always simple to determine what elements should be tested (e.g., which software modules, business processes, and/or transactions), or how conduct the testing of those elements. Building an effective and relevant testing suite is usually a time-consuming process, built on trial and error and domain know-how. Until an effective testing suite is built, and organization may end up conducting inefficient and/or incomplete testing of its systems.
One hurdle faced by test designers is the vast diversity of system options and system behavior that may be encountered and need to be tested. For example, business processes may have different behaviors to cover different options, different users, and\or for special cases. Generating tests that cover all cases is not trivial; it may require foresight, imagination, and experience that may not be available to the test designer. For example, the test designer may not be aware of certain options that are available in the system since they were never utilized by the organization to which the test designer belongs; however, a recent update to the system has caused these options to be applicable for the organization. In this case, the test designer may not anticipate, nor have knowledge of how to test, the new options.
It is often the case that software systems belonging to different organizations utilize many software modules that are the same or similar, and/or software modules that involve similar customizations. Consequently, testers belonging to the different organizations often end up running tests for testing those same or similar components. Thus, were organizations able to utilize each other's testing-related knowledge, they might be able to expand their testing arsenal and come up with more effective, comprehensive, and relevant tests. For example, after an update to a certain software module, a certain organization may devise a few tests to verify the system's performance. The test designers at the certain organization may have overlooked certain aspects of the module, which they did not include in the tests. However, test designers in other organizations may have identified those aspects and addressed them in the tests they devised. Were there sharing of information between organizations, the tests devised for the certain organization might have ended up including the overlooked aspects.